I'm going to code something from scratch. Tell me what to code.

[Thunder-squall]

Not a big deal, but I've got the basics of some visuals working (see gif).

[Ice] The cylinder will be used for ice blocks, and for puddles.  The color will shift from blue to white as the height shifts from 0 to whatever the height of the ice block will be.

[Wind] The tornado was made to resemble the one in Dark Dawn. The thing next to it is that base for air-panels. I figure they'll be purplish as they were in DD.

[Earth]  I don't need to be able to rotate the cubes fully, so I think what I have is fine for blocks that can be pushed around.

[Thunder-squall]

Here's some documentation I've been working on.  I offer it up for review and criticism.  Is it easy to understand?  Would you format things differently?

(everything within the --[[  ]]-- are comments.)
 
--[[ THEORY

   coordinate axis

         -y  
           | -z
           |/  
  -x - - o - - +x
          /|
       +z |
         +y
   
   ROTATION
   
   Assume that the axis can only rotate
   around the x and y axis, and not the z axis.
   
   rx,ry -- rotation about the x and y axis
   
   Rotation ranges from 0 to 2, and must be
   multiplied by pi (~3.14) to yield radians.
   
   SCALING
   
   I want to calculate different scaling factors
   for each of the axis, depending on the rotation.
   Following are the equations to calculate the
   x and y scaling factors of the x, y, and z axis.
      
   x_sx= cos(ry)
   x_sy= sin(rx)*sin(ry)*-1
   z_sx= sin(ry)
   z_sy= sin(rx)*cos(ry)
   y_sy= cos(rx)
   
   ROTATING
   
   As the axis is rotated, it must be kept within
   bounds (0-2), and the scaling factors must be
   recalculated.
   
   ZOOM
   
   This value is normally at 1.  The scale values
   can be multiplied by this, to create the effect
   of zooming in or out without distorting the screen.
   
   USE CASE
   
   All functions which draw things on screen will
   need to reference an axis object, and will need
   to access the scaling variables of that axis.
   
   EXAMPLE
   
   drawShape={} is the list that will contain some
   functions that draw pseudo 3D shapes on screen
   
   An example of a function is
   drawShape.sphere(x,y,rx,ry,rz,axis)
   which will draw a 3D round shape.
   
   'x,y' are the positions something is drawn on screen.
   'rx,ry,rz' are the radii along each given axis
   'axis' is the axis object
   if it not included, the funciton will assume
   rx,ry = 0,0, and zoom=1.
   
   OTHER EXAMPLES
   
   Each side of a cube will be drawn using it's own
   function:
   drawShape.topSurface(x,y,dx,dz,axis)
   drawShape.bottomSurface(x,y,dx,dz,axis)
   drawShape.leftSurface(x,y,dz,dy,axis)
   drawShape.rightSurface(x,y,dz,dy,axis)
   drawShape.frontSurface(x,y,dx,dy,axis)
   drawShape.backSurface(x,y,dx,dy,axis)
   
   ADVANCED USE CASE

   Shapes like cubes will be drawn using other shape
   functions (like the ones documented above),
   but the order in which those shapes are drawn
   will change depending on the rotation of the axis.
   
   The algorithm that determines this will be the same
   algorithm that decides the order in which objects at
   different coordinates will be drawn on a larger grid.
   When I make that function, it will also require an
   axis input variable.
--]]

[Thunder-squall]

Just started looking at things again, and here's a project of someone else's: [v1.1] Block Pusher .  It's similar in appearance to what I'm using to test movement and map editing, but the reason I'm posting it is because it brings up the question as to whether to limit player movement to a grid, or to let them roam freely... I'm not going to post the long discussion I've had in my head, but I've reached the following compromise:

1) Let players roam freely when they are not engaging or interacting with level objects that are part of a puzzle.
2) When players are moving puzzle elements (like blocks), restrict their pushing, pulling, or psi energy actions to a grid.

But  then there's the weird issue of having to have players "snap" into position when they engage with blocks, and that just seems odd.  But what choice do I have if I'm to have both free movement and limited movement on the same map?

[Misery]

That compromise sounds good to me. My first thought is to make the player move into place before starting the interaction with the gridlocked object, using whatever their normal movement is rather than snapping them there. Think of something like when you're about to grab onto a ladder. You have to make sure it only happens when the player is actually trying to interact with the object though, or it could become annoying.

I even found someone who could skew tiles to those cube surfaces, to get a pseudo 3D thing going on

I know this is a bit late, but do you remember where you came across this? Got any links, or know how they did this?

I finally started building a prototype for my game this weekend, using löve no less. Not sure if I'll do the "pseudo-3D" thing even if I can figure it out, but at one point that seemed like the best solution, and I'm still kind of interested since it doesn't seem as if anything like that is supported by just using löve's built-in graphics functions.

Also, did you make some löve/lua help/discussion thread somewhere? Or did I dream that? Because I clearly remember it, but I can't find it... well, I don't have any questions at the moment, but I might at some point...

[Thunder-squall]

I can help with any love2D questions.  I'll answer any thread or post which you make.

EDIT: My advice on beginners software for using Love2d:
> Love2d v.9.0 (https://love2d.org/)
> NotePad ++ (http://notepad-plus-plus.org/)
> 7-zip (http://www.7-zip.org/)

All of it's free and stuff.

-----------

I have something called "wrappedbox.love" which applies a square texture to faces of a cube, but it needs to be updated to love 9.0.  Here's what I hope to have for you soon:

> A program with a rotating box, that has a texture on it.

Big whoop, right?  But it's got some improvements which I think were necessary to go forward.  And it should be easy to read and learn from.  I hope to take care of the pseudo 3D thing so you don't have to, and I essentially want to be able to take any 2D map and interpret it in a 3D space.

-----------

Personally, my goal is to make a version of the mercury hack, using the same puzzle elements and such.

[Misery]

Thanks, I'll get back to you in a day or a few. Just saying because I kind of have to leave in a hurry.

[Thunder-squall]

It's been a while and I've reached another stopping point, so here's an

update.  

1. A redone coordinate system, which can be used for coordinates, as well as actual distances.  Can also have negative coordinates.

2. A way of reorganizing the order in which objects are drawn, so the stuff in front appears at the front.

To do / problems

1. There's some clipping when the player can move freely between grids.  This is because the draw order for each object is based on a single point within the object, and not the extremities of objects, which might stick out past the origin of others.  I can fix this by drawing stuff with larger y values (that are higher up in the sky) last.  I won't use this for a given object (i.e. the sides of a cube), but I will do this for objects on the field/grid.  If that doesn't fix the problem, I'll find another way, or just limit the player's movement to the grid.  But that should be the end of my 'draw order' problems,

2. I'm going to change the way the player moves based on the controls.  So if players press 'left,' their avatar will move what looks like left to the player, even if the movement won't be strictly along the x - axis.  I think that's going to be necessary if I'm going to have free movement.  I've set the ground work for this already.

attachments

Some pics that show the peculiar points of some of my decisions, and a .love file.  As always, to play the love file you need the download from love2d.org. To open it up and edit it, you just need to unzip it using something like 7-zip.  It may or may not help to manually change the '.love' to '.zip' first.

You can if you want to, but I'm not asking anyone to look inside the code right now.  Part of the reason I'm taking a break now is because I know I'm going to have to "clean up my room," so to speak, and I'm just not in the mood for that right now.

But if you can, please do download the love file,
and test it by pressing WASD, Q E, the direction keys, and page up / page down.

[Misery]

The 3D you do has the quirk that things further away appear larger from certain angles... hate to be the one to point it out, but I think it needs to be addressed at some point, and better now than later.

Other than that, sounds like you're working to fix the current issues.
I remember looking at your code for one of your earlier versions of the character mover, but I couldn't really figure it out... not sure if it's because I don't know enough math, or you work some Lua magic I haven't learned yet, or if it's simply too hard for me to get into someone else's code. I think it may need some tweaking though, because of the perspective issue mentioned above.

Now...

Thanks, I'll get back to you in a day or a few.

Or 3 weeks, apparently. Not exactly what I planned, but...

First of all, good recommendations for programs. 7zip and notepad++ are what I've been using all along, haha.

The update to v.9.0 has caused me a lot of headaches when trying to learn stuff, with most tutorials using outdated methods and no demo programs working, so thanks for offering to help.

Anyway, I was mainly going to post to give you an idea of how far I've gotten. I haven't touched this since back then though. What I have is a way to draw terrain with adjustable elevation, and gotten started on a very basic menu. Current next step is a function to spawn characters and creatures from the menu. The current goal is to make a simulator for the battle system and to have working character customization menus (stats and equipment, not visuals).

You could look at the code - I'd prefer you don't, since this is my first love2d program barring stuff like "hello world" and "draw a square". I probably don't really know what I'm doing. But I figure it's only fair since you've been sharing yours all the time.

Instructions
Arrow keys: move the marker
Return: open menu/select option
Z: select option (menu)
X: go back (menu)

num+: raise terrain
num-: lower terrain
H: hide/show outlines
T: hide/show texture (placeholder texture)

[Thunder-squall]

@ z.love
That looks pretty sweet!   Truth be told,  I don't think we even *need* rotation, nor is it desirable if we eventually want to use pretty isometric pictures and stuff.

What you've built is also a good step towards what I imagine a map editor would look like.  And in fact, if you have thoughts on the way an editor would work, it's something I want to talk about.  I think I even created a thread for it at some time.

Current next step is a function to spawn characters and creatures from the menu. The current goal is to make a simulator for the battle system and to have working character customization menus (stats and equipment, not visuals).

Could you describe how it'll work?  That way I can think about the same problems as well, and suggest stuff.  For example, I might start with something like

Spoiler for Hiden:

enemiesOnField = {} -- it's an empty table right now

function createEnemy()
   local enemy = {}
   enemy.position={ 3 , 4}
   -- other information and stuff
   return enemy
end

function addEnemyToField{enemy, field}
   table.insert(field, enemy)   
end

and of course other problems arise, such as identifying enemy type, behavior, and interaction.  These are things I need to figure out too, so if you pose a challenge, we can work on it together.

... the character mover, but I couldn't really figure it out...

I don't know the specifics so I can't help much, but here's a basic tutorial which I think might help lurkers take part too, if they're so inclined.  It has to do with the "dt" of love.update(dt).

(note:  I haven't tested this code, so I apologize if you end up having to debug it)

just the code (put it in a main.lua file)

Spoiler for Hiden:

function love.load()
   x , y = 100, 100 -- random coordinates, between 0,0 and 800,600
   s = 100 -- speed
end

function love.update(dt)

   local lkd = love.keyboard.isDown

   if lkd('right') then
      x = x + s * dt
   end
   
   if lkd('left') then
      x = x - s * dt
   end
end

function love.draw()
   local lg = love.graphics
   lg.print('press right or left', x , y )
end

with annoying comments

Spoiler for Hiden:

-------------------

-- The double dash signifies the beginning of a comment.  Comments do not impact the code.
--[[
This is another way to make comments
--]]
function love.load()
   x , y = 100, 100 -- random coordinates, between 0,0 and 800,600
   s = 100 -- speed
end

function love.update(dt)
   --[[ What is dt?
      Every computer runs at a different speed.
      dt is a variable that standardizes speed across computers.
      So if you say x = x + dt,
      then it'll take 1 second for x to equal x+1
   --]]
   
   if love.keyboard.isDown('right') then
      x = x + s * dt
   end
   
   local lkd = love.keyboard.isDown -- I like using temporary variables to store functions,  because they're just faster to write.
   
   if lkd('left') then
      x = x - s * dt
   end
end

function love.draw()
   local lg = love.graphics
   lg.print('press right or left', x , y )
end

If it's stuff about the axis.lua file that stumped you, then truth be told I basically took that file from [that love program I've been meaning to post but I can only find the v.8 of it], with only minor modifications.  

I was going to post my latest update, but I feel there are still two major things I want to fix first, and I don't want to spam the thread with .love files lest people get tired of them.

[Misery]

@ z.love
That looks pretty sweet!   Truth be told,  I don't think we even *need* rotation, nor is it desirable if we eventually want to use pretty isometric pictures and stuff.

What you've built is also a good step towards what I imagine a map editor would look like.  And in fact, if you have thoughts on the way an editor would work, it's something I want to talk about.  I think I even created a thread for it at some time.

Yeah. I first made the height adjustable to test my drawing method, but this has the groundwork for a level editor - just add the ability to export/import map data. Right now maps are just a table of height data, but I don't think any more than that will be needed. Not sure what thread you're referring to.

As for whether rotation is necessary or not, you'll see the obvious problem in the attached image. However, I think I will just work around it by not making it possible to step on tiles where you can't see the characters (or enemies). I've been looking a lot at Disgaea for reference, and this game uses about the same scale and almost exactly the same character size. As you probably know, that game allows you to rotate the level limited to four steps, so that sprites can still be used for character graphics. I was mainly interested in pseudo-3D for a way to texture surfaces, but after thinking a bit about it I realized I don't need it for that. Also note that height differences on maps aren't meant to be nearly as extreme in this game as they can be in Disgaea.

z.love... I named it that because it makes it end up at the bottom of the list, and I can just drag-select all my other files and compress. I saw someone explain how to use a batch file to run the program without needing to compress the parts into a .love, but I've been too lazy to learn how to do that.

Current next step is a function to spawn characters and creatures from the menu. The current goal is to make a simulator for the battle system and to have working character customization menus (stats and equipment, not visuals).

Could you describe how it'll work?  That way I can think about the same problems as well, and suggest stuff.  For example, I might start with something like

Spoiler for Hiden:

enemiesOnField = {} -- it's an empty table right now

function createEnemy()
   local enemy = {}
   enemy.position={ 3 , 4}
   -- other information and stuff
   return enemy
end

function addEnemyToField{enemy, field}
   table.insert(field, enemy)   
end

and of course other problems arise, such as identifying enemy type, behavior, and interaction.  These are things I need to figure out too, so if you pose a challenge, we can work on it together.

Oh, uh... I know what I'll start with. The function will add a graphic to the map at the marker's current location, tied to an entry in a list (table). After that, I'll work on associating more data with them, but it might be kind of daunting at that point because I have so many contributing variables - stats are dependent on the combination of class, equipment, character attributes, and a few more things. At least I have my plans well documented, so I guess just start out with placeholder values, but ultimately I want the functionality to customize all that from within the game.

Probably not going to start with enemy AI for some time... player controls aren't that far off, though.

If it's stuff about the axis.lua file that stumped you, then truth be told I basically took that file from [that love program I've been meaning to post but I can only find the v.8 of it], with only minor modifications.

When I was looking at your program, this was mainly what I was looking for - how to calculate the shapes of the rectangles (i.e. the polygon coordinates). I've realized I need delta time for scrolling and animations though, among other things, but haven't quite figured out how it works yet. I'll take a look at the tutorial later.

Sorry for hijacking your thread, btw. I'm not sure if I'm ready to make a thread for this project yet.

[Thunder-squall]

@ Rotations and textures

If your end goal is Disgaea, then you will need rotation, and you will need to skew textures.  I found the 'wrapped box' love program that I've been talking about, and made small changes to the conf.lua file so it runs with love2d (I changed "screen" to "window").  It shows that skewing textures is within reach, although the specific program will have to be changed depending on how we define and draw our maps.

WAIT. No, you're right.  Disgaea's images are set up that the top surfaces can just be rotated, and the side textures just need to be squished... I think.  But if that doesn't work, then we can still wrap textures to boxes.

See "wrapped box_loveV9.love" attachment.

@ running the game without making a .love file

Drag the game folder (with the main.lua file in it) over to a shortcut for love2d (looks like a blue orb).

I've attached an image that might help explain it.

@ Polygon coordinates

I'm going to have to redo my stuff, and as I do, I'll post better examples and tutorials.

Attached is where I left off, just for reference.  The horizontal controls should be improved.  The other stuff... has reasons for why they're not fixed (or the fixes were bad ideas), and I'll address those as I remake the stuff...

@ Different threads

I think we're basically working on the same thing, towards the same goal, so it makes sense to use this thread to talk about what we've been talking about.

Oh, uh... I know what I'll start with. The function will add a graphic to the map at the marker's current location, tied to an entry in a list (table).

After that, I'll work on associating more data with them, but it might be kind of daunting at that point because I have so many contributing variables - stats are dependent on the combination of class, equipment, character attributes, and a few more things. At least I have my plans well documented, so I guess just start out with placeholder values, but ultimately I want the functionality to customize all that from within the game.

Are you thinking in terms of a tactics game, or a more traditional Golden Sun turn based battle?


EDIT
found this cool youtube video just now, that someone put up just this march.
Made in lua/love2d.  I would love to adapt something like this into what I'm building.
It's basically a light and shadow system.
https://www.youtube.com/watch?v=6V5Dtsa6Nd4

[Misery]

Oh, no, I guess I could have worded that better. My goal is not Disgaea in any sense other than the scale, I've been using it to get a feeling of what is a good size for characters on the screen, how much of the map you should see, stuff like that. I always find myself zooming out in Disgaea to see the whole map, but in this game you won't be giving a destination to your characters, you control them directly. And I'll probably include a mini-map. So I think the zoomed in screen size will be perfect. And I probably won't need rotation.

I guess I forgot to mention, but battles take place on the map, like a tactics game. That's why position and elevation and that stuff is a big deal.

My reason for doing this is the game project I'm working on, that I mentioned at some point and maybe some other point too. I have a very defined idea of what I want to do, so I'm not sure if we can say we're working towards the same goal, even if our projects probably have a few interests in common. I don't feel like I'm ready to share it with the world until I have some graphical content to show, but if you're interested in discussing it, we can do so in PMs.

I found that lighting demo too a few weeks ago. Very cool, but way over the top for what I'm aiming for.

[Luna_blade]

@Game with tactics
You mean something like Tactics Ogre/Final fantasy tactics?
That would be cool.

[Misery]

Yes, you could say that. I still haven't played either of those, shame on me. But what I mean is that it doesn't switch to a separate screen for battles, unlike Golden Sun.

[Thunder-squall]

alright, let me know if you need anything.

[Today]

Today at 16:40:10

Luna_blade: @Saturos: Your english exams?

[Today]

Today at 16:33:40

Teawater: Can't remember exactly what shae of yellow it was, so not sure it would be too close or not.

[Today]

Today at 16:30:58

Teawater: @KoP: Wouldn't Shiny Gold be for the Sol Clan?

[Today]

Today at 15:37:37

Salanewt: Oh wait, tag doesn't work down here. But yeah, how is your hack going Jamie?

[Today]

Today at 15:37:00

Salanewt: [me] considers giving him the Sol Blade...

[Today]

Today at 15:36:00

Salanewt: Oh my. To be honest though, I'd be more likely to give Briggs stuff from later regions; him being a pirate from another continent and all.

[Today]

Today at 09:36:58

JamietheFlameUser: How not to design boss fights: give human-type bosses stats and equipment on par for what the Editor says their level is and what equipment is available where they're from. You get stuff like an actually scaled to level 21 Briggs with a Great Sword, Silver Plate, Silver Helm, Vambrace, and Leather Boots. God, that was BS.

[Today]

Today at 09:09:49

Saturos: Wow first part of exam is ower (in english) tomorow speaking part.

[Today]

Today at 07:11:35

JamietheFlameUser: Eh, I didn't know the exact chance of Curse screwing you over. Still, that 6% chance to fail to act at all could screw you over when it matters most. The obvious solution, of course, is to stick that armour on a character who doesn't do anything but spam attack moves anyway.

[Today]

Today at 07:10:52

leaf: ...assuming I'm remembering the chance of curse taking effect correctly as 25%

[Today]

Today at 07:09:50

leaf: in fact, you get two turns the majority of the time (~56%), and only completely fail to act ~6%, the remainder of the time getting one action

[Today]

Today at 07:07:49

leaf: I like that stealth armor buff. it wouldn't make sense to do that with the clerics ring available, but if you remove that, it's actually an interesting item. On average, you get ~1.5 turns per round. it's potentially very strong, but carries risks

[Today]

Today at 07:04:59

leaf: lol

[Today]

Today at 06:39:21

JamietheFlameUser: Reading the Venus Psynergy topic and 'lol'ing at Role's reaction to a very simple spell idea I'd had (and still think is awesome), where rock explodes out of the ground from a single point in a focused, cone-shaped burst. Role read me the riot act about not combining elements again. lol.

[Today]

Today at 06:17:58

JamietheFlameUser: Well, one thing I came up with that was actually potentially cool is a modification to the Stealth Armour. I gave it +1 turns, under the assumption that the Cleric's Ring would be removed. You might get 2 actions that round, or 1 action, or maybe no actions at all! RNG at its finest.

[Today]

Today at 06:15:32

Knight of Purgatory: Nice orange text kain. Maybe it should be a shiny gold

[Today]

Today at 06:03:40

leaf: I concur. There isn't much I'd consider worth salvaging from dc in terms of work done, but reading the old threads can be quite amusing

[Today]

Today at 06:01:48

JamietheFlameUser: LOL I'm looking at the DCrisis Items/Equipment section. Role and I were both so immature about it (me especially) that it's hilarious in hindsight.

[Today]

Today at 01:49:48

Knight of Purgatory: Then i think i'll take the entire shop, item and equipment section

[Yesterday]

Yesterday at 23:25:55

Teawater: @Kain: That's certainly nice to know. :)  Poetry time, I go.  Eventually, things will be in automation. As long as there's no procrastination. In the future, say hello to Mr. Name Charger. Don't worry, it's not a Danger. There'll also be Mr. Clan Swapper.  It might make people hyper..... (Or does the best refer to something else? Like the badge shop?)

View All

refresh